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AMENDMENTS TO THE SPECIFICATION ; 

Please amend the paragraphs beginning at page 3, line 14, as follows: 
KNOWN SOLUTIONS AND PROBLEMS WITH THESE. 

One suggested solution to the problem of administration is to implement separate support for 
administration of each type of application. The major problem with this method is, firstly, that 
for each new supported multi-user application the administration has to implement a new set of 
administration mechanisms, and secondly, that the administrator has to integrate the new set of 
administration mechanisms with existing administration for other multi-user applications. 

Another suggested solution to the same problem is to support only multi-user applications that 
use a standardised protocol such as for example the Hyper-Text Transfer Protocol (HTTP). This, 
however, leads to other problems, as use of a single protocol will make it very difficult to make 
multi-user applications work in the network because of their different nature and their different 
resource requirements. 

OBJECTS OF THE INVENTION. 

It is, th e refore, an object of the invention to provide a solution to the problems outlined above, 
and which overcome th e problems of the known solutions 

BRIEF DISCLOSURE OF THE INVENTION. 

The pr e sent invention provid e s a syst e m recited in the accompanying independent claim 1, a 
method recited in the accompanying independent claims 2, 8, 9 and 10, and an 

Please amend the paragraphs beginning at page 4, line 1, as follows: 

arrangement recited in the accompanying independent claim 7. Other advantageous features of 
the invention are recit e d in the accompanying dependent claims 3 — 6 and 1 1 — Wr 
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The present invention proposes a solution to solve the problem of administration of different 
multi-user applications is solved using by means of the H.323 standard according to ITU-T 
Recommendation H.323, 02/98 "Packet-based multimedia communications system", which is the 
standard mostly used for systems providing multi-media traffic today . Establishing and 
administrating connections between clients and their respective servers by means of H.323 T 
according to the invention, provides the advantage of allowing a system that includes application 
specific protocols as well as one common standard protocol, namely the H.323. 

Please amend the paragraphs beginning at page 5, line 1, as follows: 

| DETAILED DESCRIPTION OF THE EMBODIMENTS. 

In the following, the present invention will be d e scribed by way of e xample and with r e ference 
to the accompanying drawings. 

Referring to fig. 1, when the client is started, it first uses a known registration process of H.323 
version 2 to be registered and authorised in the network. It should also be noted that, in the 
situation illustrated in fig. 1, the server is already registered in the H.323 network. When using 
H.323, the client side of the application and the server side of the application must both support 
the H.323 stack. Further, to have full service, the server must be running all the time. Through 
the registration process, the user is authorised (authorisation is new in version 2 of H.323). This 
means that the operator can decide who is allowed to contact the server. Up to this point, 
conventions and interactions in the network are according to the known steps of the H.323 
version 2. 

Now, referring to fig. 2, when the client initiates a call with the gaming server as the destination, 
the gatekeeper will check in the userls profile, which is received from a User Handling Database 
(UHD), to see if the users is allowed to use the gaming server, denoted by Gaming Server Info4n 
fig, 1 . In order to fetch this data and to perform the evaluation, new functionality is added to a 
normal H.323 Gatekeeper. If the user is found to be allowed to "call" the gaming server, then the 
gatekeeper informs the client that he is allowed to make the call set-up as is typically done 
according to H.323. 
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Then the client starts the data channel of H.323 towards the server. This is allowed according to 
H.323, although it is not usually done this way as the procedure usually employed is to start 
voice and video channels. According to one example embodiment of the invention, the H.323 
protocol is extended to support a new codec. This is shown below: 

For the purpose of simplifying the explanation of the solution of the invention by way of 
example, in the following, H.323 and H.323 names and terms will be employed extensively. A 
new codec that is specialised for real-time data transfer is employed has to be developed . In 
H.323 the new codec is has to be identified in the ASN.l syntax as described below: 

Please amend the paragraph beginning at page 6, line 36, as follows: 

This basis for the example ASN.l code shown above is described in ITU-T Recommendation 
H.245, 02/98 "Control protocol for multimedia communication". The code above, being an 
amended code applicable to solutions according to H.245, shows how the Data Application field 
of the H.245 protocol is advantageously extended to accommodate the invention . In system 
operating according to the inv e ntion, such Such adaptation of H.245 is included in all clients, 
servers, and gatekeepers having that has registered gaming servers to them (if the gatekeeper is 
routing H.245 h.2 4 5 ). In this context, the particular name of the new codec is not relevant, just 
that it is a-new-ene. Any requirements for more than one new codec in a particular system wiH 
depend on the requirements defined for the communication between the client and the different 
types of gaming servers. Regardless, What is important, though, is that a game server and all of 
its connected clients must provide support for the same codec type. 

Please amend the paragraphs beginning at page 7, line 1, as follows: 

The new codec is designed in a simple fashion, meaning that it requires little overhead. In the 
followin g example , some of the characteristics of the new codec are given: 

• The codec uses RTP (Real-time transport Protocol) over UDP (User Datagram Protocol) to 
obtain real-time transport 
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• The codec includes mainly twote types of messages: a) a data message, and b) a control 
message. 

• The data message can be sent from the client or from the server. The control message is only 
sent from the server. 

Please amend the paragraphs beginning at page 7, line 31, as follows: 

Note that time-stamps and sequence numbers are+s not part of the new codec messages, because 
this information typically can be obtained from the RTP header. 

Now, with reference to the accompanying figures 6 and 7, and by way of example, information 
exchange in a client-server configuration in an example embodiment of the invention will be 
explained. The referenced figures 6 and 7 generally show examples of the communication 
sequence between a client and a server. In the sequence examples 

Please amend the paragraphs beginning at page 8, line 1, as follows: 

shown, there are some common steps. The client initiates the communication by sending a 
"setup" message according to the standard call control protocol which has been selected; that is, 
for example g en e rally , H.323 or SIP. Then the server signals accept ance aeeept of the incoming 
"setup" by sending an accept message according to the selected call control protocol. The call 
control part of the client then sends a suggested media set and address, including the new codec. 
Further, as shown in the examples, the suggested media set is accepted by the server by a 
message that also includes the media destination address to which the client is to send the media. 
At this point in the sequence, two different possibilities are available. One possibility is that the 
address is sent from the Call control towards the application part in both the server and the client, 
in which case it is the application on the client that sends the media using the new codec directly 
towards the application on the server. This first possibility is illustrated by the further parts of 
the sequence shown in figure 6. The other possibility is that the Call control on both the server 
and client sends a "start" message, or a similar kind of information, indicating that 
communication is now established between the server and the client. In this latter case, media 
sent in the new codec is first transmitted from the application towards the Call control and then 
from the Call control on one side over to the other Call control, and then on to the application. 
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This other possibility is illustrated by the further parts of the sequence shown in figure 76. At 
the termination of a session, the client send a "close" message. However, closing can also be 
initiated by the server. The entity receiving the "close" message informs the application that the 
session is over, and responds to the "close" message by sending back an "accept" message. 

Now, with reference to figures 4, 5, 6 and 7, the message types and their use will be explained by 
way of example. In accordance with a sequence as described above, the sever can first send a 
control message including information specifying the rate at which data is to be be sent 
fromfe fffl-the client to the server, and possibly also information about the data type. In turn, the 
client sends data to the server at the specified rate and of the specified type, according to the 
scheme specified in the control message. Such control messages can be sent at any time during a 
session, in order for the server to specify different data rates and data types according to the 
needs of the application associated with the session. 

Please amend the paragraph beginning at page 9, line 15, as follows: 

Further, as illustrated in figures 6 and 7, when seen in conjunction with the messages described 
with reference to figures 4 and 5, when establishing the data channel, the client informs the 
server of which protocol to use for the data communication using . For a system according to 
invention, this is to be the new codec as described above. This means that the applications 
themselves can use whichever protocol they desire, as long as it maps into the new codec type. 
During the H.323 set-up phase, both the client and the server also inform each other of ports on 
which they want to receive data, and of which transport protocol is to be used, such as e.g. 
whether they use TCP (Transmission Control Protocol) or UDP (User Datagram Protocol). This 
information can further be used by a H.323 Proxy to enable the chosen data protocol to be 
transferred through a firewall, as illustrated in fig. 3. If an H.323 proxy is used, it also will be 
updated with the enhanced H.323 protocol. 

Please amend the paragraph beginning at page 10, line 21, as follows: 

The procedure of authenticating H.323 end-user in H.323 systems is specified in H.323. 
However, it is only specified how the user name and password can be sent from an end-user to 
the gatekeeper. To obtain true authentication, a means for checking the username against the 
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password must be added to the system. One Qn way of allowing this check to be accomplished is, 
as illustrated in the accompanying figures 1, 2 and 3, to add a database to the gatekeeper. This 
database will at least include a record for each user containing a username and a password. The 
gatekeeper will then check if the end-user exist in the database. If the end-user exists in the 
database, then the gatekeeper obtains the password of the user and checks to see if it matches the 
password received by the end-user. The database and its associated logic is in this solution 
referred to as the User Handling. The data that determines if the user is to be allowed to make a 
call can be added to the user record stored for each user in the database described above. 

Please amend the paragraphs beginning at page 11, line 11, as follows: 

Although only a simple H.323 network is shown in the figures 1, 2 and 3 to simplify the 
drawings for the purpose of explanation explaining th e inv e ntion , the solution described provided 
by the present invention will also work in large-scale H.323 networks or in networks having an 
architecture and/or operating according to similar call control protocols, such as for example the 
SIP protocol. 

ADVANTAGES 

By using H.323, the applications can easily be integrated with voice and video if they do not 
already have this support. This will give some application a new dimension without the need for 
making large changes the application required otherwise. When using H.323, the client does not 
need to know the IPdntemet ProtocoD-address of the server, as the H.323 supports more 
advanced address schemes like E-164 numbers, e-mail addresses, or aliases. 

When using H.323, the cli e nt does not n ee d to know the IP(Internet Protocol) address of the 
server, as th e H.323 supports more advanced address schemes like E 1.64 numbers, e mail 
addresses or aliases. 
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